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Beschreibung 

Universelle Bewegungssteuerung 

Die Erfindung bezieht sich auf eine universelle Bewegungs- 
steuerung mit Engineering- und Run -Time -System, welche funk- 
tionell die klassischen Aufgaben einer speicherprogrammierba- 
ren Steuerung und einer numerischen Steuerung in sich verei- 
nigt . 

Es ist heutzutage ublich, sowohl fur die speicherprogrammier- 
bare Steuerung als auch fur die Bewegungssteuerung jeweils 
unterschiedliche hierarchische Ablaufebenen zu modellieren, 
denen Software-Tasks zur Steuerung des jeweiligen technischen 
Prozesses zugeordnet werden. Diese Tasks konnen Systemaufga- 
ben erfullen, sie konnen aber auch anwenderprogrammiert sein. 

Es ist bekannt, daS bei einer speicherprogrammierbaren Steue- 
rung "SPS", also auch bei einer Bewegungssteuerung "NC", An- 
wenderprogramme bzw. vom Anwender erstellte Tasks in den 
Speicher der jeweiligen Steuerung zugeladen und zur Ausfuh- 
rung gebracht werden konnen. 

Aus der DE 197 40 550 Al ist es bekannt, daS ProzeSsteue- 
rungsf unktionalitaten der speicherprogrammierbaren Steuerun- 
gen "SPS" und Bewegungsf unktionalitaten von NC-Steuerung in 
einem einhei tlichen konf igurierbaren Steuerungs system integ- 
riert werden konnen. 

Diese SPS/NC-Integration geschieht in Form des Zusammenschal- 
tens von SPS- und NC-Steuerungsbaugruppen . Bei einer solchen 
Ausfuhrung der Integration wird aber keine optimale und effi- 
ziente Taskstruktur fur die Gesamtheit der Steuerungsauf gaben 
erreicht. Aufierdem kann bezuglich der ProzeSsteuerung, also 
auch bezuglich der Bewegungssteuerung, erweiternde Funktiona- 
litat nur in Form von Anwenderprogrammen nachgeladen und zur 
Ausfuhrung gebracht werden. 
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Es ist heutzutage ublich, Steuerungen mit Parametrierinf orma- 
tionen zu versorgen. 

Parametrierinf ormationen umfassen in diesem Zusammenhang 
die Beschreibung von Systemvariablen mit Datentyp, Attri- 
buten und Beschreibungstexten, 

die Beschreibung von Alarmen, mit ihrem strukturellen Auf- 
bau, Attributen und Alarmtexten, sowie 

die Beschreibung von Sprachbef ehlen (Bewegungs- und Tech- 
nologiebef ehle) mit Syntax und dazugehorigen Parametern. 

Ublicherweise werden aber diese Parametrierinf ormationen, die 
an unterschiedlichen Stellen innerhalb der Steuerung benotigt 
werden, jeweils separat an diesen Stellen in der Steuerung 
implementiert . Die Konsistenz dieser verteilt implementierten 
Parametrierinf ormationen ist nur sehr aufwendig sicherstell- 
bar . 

Der Erfindung liegt daher die Aufgabe zugrunde, fur jeweils 
unterschiedliche Steuerungsauf gaben und unterschiedliche 
Randbedingungen bzw. Anf orderungen des zugrunde liegenden 
technischen Prozesses in einfacher Weise optimale Auspragun- 
gen der kombinierten SPS/NC-Steuerungen sowohl hinsichtlich 
ihrer Steuerungsstruktur als auch hinsichtlich ihrer Funktio- 
nalitat zu erstellen und dabei sicherzustellen, dafi die in 
der Steuerung implementierten Parametrierinf ormationen immer 
konsistent zueinander sind. 

Gemafi der Erfindung wird diese Aufgabe dadurch gelost, daS 
ein einheitliches Ablauf ebenenmodell dergestalt gebildet ist, 
daS es mehrere Ablaufebenen unterschiedlichen Typs mit unter- 
schiedlicher Prioritat aufweist, wobei von hochster bis nied- 
rigster Prioritat verschiedene Anwender- und Systemebenen 
vorgesehen sind und daS jeweils Technologiepakete anwender- 
seitig in das Engineering- und/oder Run -Time -System ladbar 
sind, daS eine Datenquelle fur Beschreibungsinf ormationen fur 
Systemvariablen sowie gegebenenf alls Alarme und/oder Sprach- 
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befehle uber einen Umsetzer dem Engineering- System Sprachbe- 
fehle und/oder Systemvariablen zur Verfugung stellt, daS aus 
dem Run-Time- System die Systemvariablen mit aktuellen Daten 
des technischen Prozesses versorgbar sind und dafi uber eine 
Bedienoberf lache des Engineering- Systems weitere Eingaben an- 
wenderseitig machbar sind. 

Ein wesentlicher Vorteil der Erfindung liegt darin, daS die 
Parametrierinf orraationen der Steuerung, die sowohl im Engi- 
neering-System, im Run-Time- System, aber auch fur die Doku- 
mentation und eine etwaige Testautomatisierung benotigt wer- 
den, immer konsistent sind. Der Umsetzer, der an zentraler 
Stelle die Parametrierinf ormationen fur die Dokumentation, 
das Engineering- System und das Run-Time-System aufbereitet 
und verteilt, kann ohne grofien Aufwand Semantikchecks durch- 
fuhren. Auch konnen OEM (Original Equipment Manufacturer) - 
Kunden in dieser Datenquelle fur Beschreibungsinf ormationen, 
d.h. an definierter Stelle, aufwandsarm weitere Parametrier- 
inf ormationen fur die Steuerung erstellen und in die Dokumen- 
tation einbringen. 

Ein weiterer Vorteil der Erfindung liegt darin, daS innerhalb 
der Ablaufebenen die Tasks der Steuerung so angeordnet werden 
konnen, daS der Kommunikationsaufwand innerhalb der Steuerung 
reduziert wird. 

Ein weiterer Vorteil liegt darin, daE anwenderseitig durch 
die Zuladung von Technologiepaketen in das Engineering- 
und/oder Run -Time -System der Steuerung eine anwendungsspezi- 
fische Skalierung des Run-Time- Systems der Steuerung bezug- 
lich ihrer Funktionalitat erreicht werden kann. 

Eine erste vorteilhafte Ausgestaltung der Erfindung liegt 
darin, daS vom Umsetzer aus dem Bestand der Datenquelle rele- 
vante Dokumentationsinf ormationen an ein Ausgabemedium wei- 
terleitbar sind. Dadurch wird sichergestellt , daS alle Doku- 
mentationsinf ormationen aus einer gemeinsamen Datenquelle 
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stammen und somit immer untereinander konsistent sind, unab- 
hangig, auf welches Ausgabemedium (z.B. Drucker oder Online- 
Hilfe) die Dokumentationsinf ormation ausgegeben wird. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dafi als Ablaufebenen vorgesehen sind: 

a) eine Lagereglerebene, bestehend aus zugehoriger getakteter 
Systemebene und Anwenderebene , 

b) eine Interpolatorebene, bestehend aus zugehoriger getakte- 
ter Systemebene und Anwenderebene, 

c) eine Event -Systemebene fur reaktionspf lichtige Ereignisse, 

d) eine Anwenderebene fur asynchrone Fehler, 

e) eine weitere, vom Anwender anf orderungsspezif isch frei 
projektierbare Anwenderebene fur Alarm- und/ oder Event- 
und/oder Regelungs- und/oder sonstige zyklische Tasks, • 

f) eine aus der Abfolge von Bewegungssequenzen, freien Zyklen 
und niederprioren sonstigen Systemtasks, gebildete Ebenen- 
gruppe fur Hintergrund-Bearbeitung, 

wobei die Ablaufebenen a bis e eine Ebenengruppe fur Echt- 
zeit-Bearbeitung bilden. 

Ein wesentlicher Vorteil dieser Schichtung liegt darin, daS 
die Kommunikation zwischen den Tasks der Prozefisteuerung und 
denen der Bewegungssteuerung minimiert wird. Dadurch kann die 
Programmierung der Steuerungsauf gaben fur die ProzeSsteuerung 
und fur die Bewegungssteuerung in einer einheitlichen Pro- 
grammiersprache mit einer einheitlichen Erstelloberf lache er- 
f olgen . 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dafi die Technologiepakete beinhalten: 
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a) Code-Teile, die die Regelungsspezif ika fur das Run-Time- 
System reprasentieren und 

b) einen Konf igurierteil der die Zuordnung dieser Code-Teile 
2u den jeweiligen Systemebenen, sowie deren Bearbeitungs- 
folge aufweist, wobei 

c) bedarfsweise diese Inf ormationen des Konf igurierteils auch 
an das Engineering-System weiterleitbar sind. 

Somit ist es moglich, daS der Anwender durch dynamisches Zu- 
laden solcher Technologiepakete die Moglichkeit einer techno- 
logischen Skalierung des Run -Time -Systems der Steuerung be- 
sitzt. Damit kann der Anwender ausgehend von einem Basissys- 
tem der Steuerung den Bef ehlsvorrat dieses Basissys terns bzw. 
Betriebssystems dynamisch zugeschnitten auf die jeweiligen 
Erf ordernisse des zugrundeliegenden technologischen Prozesses 
Oder der Steuerungsauf gabe erweitern. Der Anwender hat somit 
die Moglichkeit, die vorhandene Grundf unktionalitat einer 
Steuerung gezielt um solche Funktionalitaten zu erweitern, 
die er wirklich fur seine Anwendungen benotigt. Das Basissys- 
tem bildet hierbei den Auslief erungsumf ang des Run-Time- 
Systems einer Steuerung, namlich ein Echtzeitbetriebssystem, 
ein Ablauf system (mit System- und Anwender ebenen) , Technolo- 
gieobjekttypen, Sprachbef ehle, den SPS-Bef ehlsvorrat sowie 
Kommunikations- (z.B. LAN, E/A) und technologische Schnitt- 
stellen (z.B. Antriebe, Geber) zum technischen ProzeS. Im Ba- 
sissystem befindet sich somit die notwendige Grundf unktiona- 
litat einer Steuerung. Das Basissystem ist dabei auf unter- 
schiedlichsten HW-Plattf ormen (z.B. PC, Antrieb, ...) ablauf- 
fahig. 

Dadurch, daS die Inf ormationen des Konf igurierteils eines 
Technologiepaketes uber die Datenquelle und den Umsetzer ins 
Run-Time-System und ins Engineering-System gebracht werden, 
lassen sich Parametrier- und Konf igurierinf oirmationen in ein- 
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heitlicher Weise in die Steuerung einbringen und ein Anwender 
kann an zentraler Stelle Anderungen in den Parametrier- bzw. 
Konf igurierdaten vornehmen. Die sogenannten Parametrierinf or- 
mationen entsprechen Datenbeschreibungen fiir ubliche und ge- 
nerelle Steuerungsaspekte, namlich Systemvariablen, Alarmen 
und Sprachbef ehlen. Die Konf igurierinf ormationen beziehen 
sich hingegen auf Technologiepakete und damit auf die Mog- 
lichkeit einer technologischen Skalierung einer Steuerung. 

Dadurch, daS jedes Technologiepaket eine angepaSte Anzahl von 
Technologieobjekttypen fur das Run-Time- System beinhaltet, 
ist es moglich, auch komplexe und anspruchsvolle Steuerungs- 
f unktionalitaten in einer iibersichtlichen und verstandlichen 
Form dem Run -Time -System zuzuladen. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, daS des weiteren Bedienoberflacheninf ormationen, ins- 
besondere Bedienparameter , und/oder Sprachmechanismen 
und/oder Deklarationsteile den Code-Teilen zuweisbar sind. 

Dadurch ergeben sich folgende Vorteile: 

Um einen Technologieobjekttyp nicht nur als nicht mehr ander- 
bare Konstante verwenden zu konnen, muS der Technologieob- 
jekttyp dem Erstellsystem die Moglichkeiten der Parametrie- 
rung fur seine instanziierten Technologieobjekte und insbe- 
sondere die vorhandenen Bedienparameter bekanntmachen . Damit 
hat ein Anwender die Moglichkeit, ein Technologieobj ekt in 
der Oberflache des Erstellsystems flexibel zu parametrieren . 

Dadurch, daS auch Sprachmechanismen zuladbar sind, ist es 
moglich, daS dynamisch der Bef ehlsvorrat des Run-Time- Systems 
erweitert werden kann. In einem Anwenderprogramm kann der An- 
wender einen solchen zugeladenen Befehl in der Form verwen- 
den, als ware er ein Befehl der Grundf unktionalitat . 
Wenn ein Anwenderprogramm mit einem solchen zugeladenen Be- 
fehl innerhalb einer Anwenderebene des Ablauf ebenenmodells 
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abgearbeitet wird, wird bei Aufruf dieses zugeladenen Befehls 
die dazugehorige Codesequenz des Betriebssystems auf einer 
der Systemebenen des Ablauf ebenenmodells abgearbeitet. Dies 
geschieht ohne Zutun des Anwenders . Durch die Zuordnung von 
5 Deklarations- und Beschreibungsteilen zu den Code-Teilen des 
Technologiepaketes wird die Flexibilitat fur den Anwender 
weiterhin erhoht. 

Ein Ausf uhrungsbeispiel der Erfindung ist in der Zeichnung 
10 dargestellt und wird im folgenden erlautert. 

Dabei zeigen: 

FIG 1 die Steuerung eines technischen Prozesses mit ge- 

15 trennter speicherprogrammierbarer Steuerung und Be- 

wegungssteuerung . Die Prograininierung erfolgt uber 
jeweils separate Programmiersysteme , 

FIG 2 die wesentlichen Ablaufebenen einer klassischen 

2 0 speicherprogrammierbaren Steuerung , 

FIG 3 die wesentlichen Ablaufebenen einer Bewegungs steue- 

rung, 

^2 5 FIG 4 eine universelle Steuerung, d.h. eine kombinierte 

S PS /NC- Steuerung mit einem dazugehorigen Program- 
miersystem, 

FIG 5 das Ablauf ebenenmodell der universellen Steuerung, 



30 



35 



FIG 6 zeigt als 00 (objektorientiert ) -Strukturdiagramm ein 

Technologiepaket , bestehend aus Code-Anteil, Para- 
meter, Firmware-Konf iguration, Technologieobj ekt- 
tyP/ Sprachkomponente und Deklarationsteil , 

FIG 7 zeigt als 00-Strukturdiagramm Technologieobj ektty- 

pen fur das Technologiepaket Kunststoff und 
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FIG 8 zeigt, wie aus einer Datenquelle die Beschreibungs- 

bzw. Parametrierinf ormationen uber einen Umsetzer 
dem Engineering-System, dem Run-Time- System und ei- 
nem Ausgabemedixim zur Verfiigung gestellt werden. 

In der Darstellung gemaS FIG 1 wird, in Form eines Struktur- 
bildes gezeigt, daS zur Steuerung eines technischen Prozesses 
TPl ein paralleler Betrieb einer speicherprogrammierbaren 
Steuerung SPS und einer Bewegungs steuerung NC stattfindet. 
Speicherprogrammierbare Steuerung SPS und Bewegungs steuerung 
NC enthalten jeweils ein Run-Time- System RTSl bzw. RTS2 . Die 
Kommunikation zwischen den beiden Steuerungen erfolgt uber 
spezielle Hilfsmittel, exemplarisch dargestellt ist ein bidi- 
rektionaler Kommunikationskanal K. Die Programmierung der 
Steuerungen durch den Anwender erfolgt in der Regel in unter- 
schiedlichen Programmiersprachen mit unterschiedlichen Er- 
stelloberf lachen . Das heiSt, durch jeweils separate Program- 
mier- oder Engineering- Systeme PI, ESI und P2 , ES2 . Der we- 
sentliche Nachteil dieser konventionellen Ausfuhrung liegt 
zum einen in der aufwendigen Kommunikation zwischen den bei- 
den Steuerungen, zum anderen in den separaten und unter- 
schiedlichen Programmier- bzw. Engineering- Systemen PI, ESI 
und P2, ES2 . Uber Ein- und Ausgange EAl, EA2 der Steuerungen 
wird der eigentliche technische ProzeS TPl gesteuert, Zwi- 
schen dem Programmier system PI und der speicherprogrammierba- 
ren Steuerung SPS bzw. zwischen dem Programmiersystem P2 und 
der numerischen Steuerung NC befinden sich Inf ozmationspf ade 
II bzw. 12, auf denen die Programme in die jeweilige Steue- 
rung geladen werden. 

In der Darstellung gemaS FIG 2 sind die wesentlichen Ablauf- 
ebenen einer klassischen speicherprogrammierbaren Steuerung 
(SPS; FIG 1), angeordnet nach ihrer Priori tat, gezeigt. Der 
Prioritatsanstieg ist dabei durch einen Pfeil symbolisiert , 
In der niederpriorsten Ebene werden, wie durch eine gestri- 
chelte Linie angedeutet, zwei unterschiedliche Aufgaben, nam- 
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lich ein freier Zyklus, d.h. "Anwenderebene freier Zyklus" 
und eine Hintergrund-Systemebene, d.h. "Systemebene Hinter- 
grund" , im Round-Robin-Verf ahren, also zeitscheibengesteuert , 
abgewickelt. Der Hint ergrund- Systemebene sind z.B. Kommunika- 
tionsaufgaben zugeordnet. Bei einer folgenden getakteten An- 
wenderebene, bezeichnet als "Anwenderebene getaktet", ist der 
Aufruftakt der Tasks bzw. der Programme dieser Ebene paramet- 
rierbar. Es erfolgt eine Uberwachung dahingehend, ob die Be- 
arbeitung eines Anwenderprogrammes dieser getakteten Ebene 
rechtzeitig abgeschlossen ist, bevor das Startereignis erneut 
auftritt, Lauft die Taktzeit ab, ohne daS das Anwenderpro- 
gramm der zugeordneten Ebene fertig abgearbeitet ist, wird 
eine entsprechende Task einer priori tatsmaSig libernachsten 
"Anwenderebene fur asynchrone Fehler" gestartet. In dieser 
"Anwenderebene fiir asynchrone Fehler" kann der Anwender die 
Behandlung von Fehlerzustanden ausprogrammieren . 

Auf die "Anwenderebene getaktet" folgt eine "Anwenderebene 
Events". Die Reaktion auf externe oder interne Ereignisse (E- 
vents) erfolgt innerhalb der "Anwenderebene Events". Ein ty- 
pisches Beispiel fur ein solches Ereignis ist das Uberschrei- 
ten eines Grenzwerts . In einer "Systemebene hochprior" liegen 
Aufgaben des Betriebssystems , welche die Arbeitsweise der 
speicherprogrammierbaren Steuerung sicherstellen . 

Die Darstellung gemaS FIG 3 zeigt die wesentlichen Ablaufebe- 
nen einer Bewegungs steuerung (NC; FIG 1) . Auch hierbei sind 
die einzelnen Ebenen nach ihrer Prioritat hierarchisch, wie 
durch einen Pfeil symbolisiert , angeordnet. Eine '^" Systemebene 
Hintergrund" und eine "Anwenderebene sequenziell" haben eine 
gleiche Prioritat, namlich die niedrigste. Diese aufgabenma- 
Sige Zusammengehorigkeit ist wie bei FIG 2 durch eine gestri- 
chelte Linie symbolisiert. Die Tasks der "Anwenderebene se- 
quenziell" werden zusammen mit den Tasks der "Systemebene 
Hintergrund" im Round-Robin-Verf ahren abgearbeitet. Typische 
Tasks der "Systemebene Hintergrund" sind z.B. solche fiir Kom- 
munikationsauf gaben. In der "Anwenderebene sequenziell" lau- 
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fen die vom Anwender prograininierten Programmteile fur die ei 
gentliche Steuerungsauf gabe . StoSt die Steuerung in einem 
dieser Programmteile auf einen Bewegungs- oder Positionierbe 
fehl, wird ein Suspend gesetzt, d.h. das Anwenderprograinm 
wird an dieser Stelle unterbrochen . Die Abarbeitung dieses 
Bewegungs- oder Positionierbef ehls geschieht in einer hochst- 
prioren "Systemebene getaktet". Ein jeder Lageregler, der in 
der "Systemebene getaktet" ablauft, fuhrt diesen Bewegungs - 
bzw. Positionierbef ehl aus . Nach Ausfuhrung des Befehls wird 
in die " Anwender ebene sequenziell" zuruckgesprungen und das 
durch Suspend unterbrochene Anwenderprogramm wird durch ein 
Resume an der gleichen Stelle fortgesetzt. Die "Systemebene 
getaktet" enthalt neben den schon erwahnten Lagereglern auch 
den Interpolations teil der Steuerung. 

Auf die niederpriorste Ebene setzt eine "Anwender ebene getak- 
tet" auf. Hier laufen zyklische Tasks ab, z.B. Reglerf unktio- 
nalitaten . 

In einer folgenden "Anwender ebene Events" sind solche Tasks 
untergebracht , die auf externe oder interne Ereignisse rea- 
gieren. Solche Ereignisse konnen beispielsweise Alarme sein. 

In der Darstellung gemaS FIG 4 wird ein technischer Prozefi 
TP2 durch eine kombinierte SPS/NC-Steuerung UMC gesteuert. 
Das Akronym UMC steht fur UNIVERSAL-MOTION-CONTROL. Die Ver- 
bindung zwischen der Steuerung UMC und dem zugehorigen tech- 
nischen ProzeS TP2 geschieht bidirektional uber Ein-/Ausgange 
EA3 . Die Programmierung der kombinierten SPS/NC-Steuerung ge- 
schieht iiber ein gemeinsames Programmier- P3 oder Enginee- 
ring-System ESS , wobei das Engineering- System ES3 ebenso wie 
bei FIG 1 eine komfortable Oberflache fur das Programmiersys- 
tem P3 zur Verfugung stellt. Die damit erstellten Programme 
werden liber einen Inf ormationspf ad 13 in ein Run-Time-System 
RTS3 der universellen Bewegungs steuerung UMC ubertragen. 
Die Darstellung gemaS FIG 5 zeigt das Ablauf ebenenmodell der 
universellen Bewegungs s teuerung . Die Priorisierung derEbenen 
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wird wie im vorangegangenen durch einen Pfeil in Richtung zur 
hochsten Prioritat angedeutet . Die niederpriorste Ebenengrup- 
pe ist die sogenannte " Ebenengruppe Hintergrund-Bearbeitung" . 
Sie besteht aus einer " Systemebene Hintergrund" , aus einer 
"Anwenderebene freier Zyklus" und aus einer "Anwenderebene 
sequenziell" . Die Tasks dieser drei gleichprioren Ebenen (an- 
gedeutet durch die gestrichelten Grenzlinien) werden zyklisch 
im Round-Robin-Verf ahren abgearbeitet . Eine auf die "Ebenen- 
gruppe Hintergrund-Bearbeitung" hoherprior folgende "Ablauf- 
ebene" ist eine vom Anwender anf orderungsspezif isch frei pro- 
jektierbare Anwenderebene FA, durch doppelte Umrandung ge- 
kennzeichnet , fur Alarm- und/oder Event- und/oder Regelungs- 
und/oder sonstige zyklische Tasks. Diese Anwenderebene FA be- 
steht somit explizit aus vier Typen von Ebenen, die wiederum 
hinsichtlich ihrer Priori taten innerhalb der Anwenderebene FA 
vom Anwender staffelbar sind. 

Typ 1 : Anwenderebene Event 

Typ 2 : Anwenderebene Alarm 

Typ 3 : Anwenderebene getaktet 

Typ 4: Systemebene parametriert 

Ebenen dieser Typen konnen vom Anwender frei wahlbar inner- 
halb der Anwenderebene FA, mit jeweils zugrunde gelegten, vom 
Anwender vergebbaren Prioritaten, angeordnet werden. Damit 
hat der Anwender die Moglichkeit, eine den Anf orderungen und 
Randbedingungen der Steuerungsauf gabe und des zu steuernden 
technischen Prozesses optimale Auspragung der universellen 
Bewegungssteuerung zu erreichen. 

In der "Anwenderebene Event" sind z.B. Tasks angeordnet, die 
auf Eingange der Peripherie reagieren. In der "Anwenderebene 
Alarm" sind z.B. Tasks angeordnet, die auf Grenzwertuberwa- 
chungen reagieren. In der "Anwenderebene getaktet" sind zyk- 
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lische anwenderprogrammierbare Tasks enthalten. In die "Sys- 
temebene parametriert " konnen von auSen zuladbare Programme 
integriert werden. Dadurch ist es moglich, daS die universel- 
le Bewegungssteuerung dynamisch urn zusatzliche technologische 
Funktionalitaten erweitert werden kann. In diese "Systemebene 
parametriert" werden ublicherweise Tasks fur langsame Rege- 
lungs- bzw. Uberwachungsauf gaben (z.B. Aufgaben mit Zyklus- 
zeiten im Bereich von 100 ms) zugeladen. 

Die nachsthoherpriore Ebene im Ablauf ebenenmodell der univer- 
sellen Bewegungssteuerung ist eine "Anwender ebene fur asyn- 
chrone Fehler" . In dieser Ebene kann der Anwender, ahnlich 
wie bei einer speicherprogrammierbaren Steuerung, die Behand- 
lung von Fehlerzustanden ausprogrammieren . In der "Anwender- 
ebene fur asynchrone Fehler" sind z.B, Tasks angesiedelt, die 
auf technologische Alarme reagieren. Der Anwender hat auch 
die Moglichkeit, innerhalb dieser "Anwender ebene fur asyn- 
chrone Fehler" eine fur die Produktauspragung spezifische An- 
zahl von Ebenen zu parametrieren . Der Ubersichtlichkeit hal- 
ber sind Einzelheiten hierzu in der Darstellung nicht ge- 
zeigt. Der Anwender kann somit bedarfsweise bestimmten 
Fehlerereignissen eine bestimmte Prioritat zuordnen. 

Als nachstes folgt die "Event-Systemebene" . Die Tasks der "E- 
vent- Systemebene" reagieren auf kritische interne oder exter- 
ne Ereignisse, wie z.B, Nothalt. 

Die nachste Ebene ist eine " Interpolatorebene " . Sie enthalt 
eine "getaktete Systemebene" und eine " Anwender ebene " , 

.Die hochstpriore Ebene ist die "Lagereglerebene" . Auch sie 
enthalt eine "getaktete Systemebene" und eine " Anwenderebe- 
ne". Die Anwenderebenen der Lageregler- und Interpolatorebene 
enthalten Tasks, die im Lageregler- bzw. Interpolatortakt 
aufgerufen werden. Die Laufzeit dieser Tasks wird uberwacht, 
das Uberschreiten einer durch das System festgelegten Zeit 
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fiihrt zum Abbruch der Ebene und ziiin Auslosen eines asynchro- 
nen Fehlers in der "Anwender ebene fur asynchrone Fehler" . 

Der Lageregler hat eine hohere Prioritat als der Interpola- 
tor, d.h, der Lageregler kann nicht vom Interpolator unter- 
brochen werden, wobei der Lageregler aber den Interpolator 
unterbrechen kann. 

Im Ablauf ebenenmodell der universellen Bewegungssteuerung 
konnen prinzipiell innerhalb der einzelnen Ablauf ebenen neben 
den bereits erwahnten, weitere priorisierende Schichtungen 
vorgesehen sein. 

Die Darstellung gemaS FIG 6 zeigt als OO-Strukturdiagramm, 
wobei die Kardinalitaten durch eine gangige Zif fern-Notation 
angezeigt werden, ein Technologiepaket TP mit seinen Bestand- 
teilen: 

a) Ablauffahige Code-Teile (Code) 

b) Parameter (PAR) 

c) Firmware-Konf iguration (FWK) 

d) Mindestens einem Technologieobjekttyp (TO) 

e) Sprachmechanismen (SPR) 

f) Deklarations- und Beschreibungsteil (ACC) 

Die 1 bis n Code-Teile (z.B. C-Funktionen) werden beispiels- 
weise fur die Bewegungsf uhrung oder die Lageregelung oder fur 
eine andere Technologie verwendet. Die Code-Teile konnen un- 
ter anderem Befehle fur Tempera turf uhrung, Temperaturregelung 
Oder fur spezielle Technologien wie z.B. Pressen oder Kunst- 
stof fverarbeitung beinhalten. Wie diese Code-Teile im Ablauf - 
ebenenmodell der Steuerung in die Systemebenen eingehangt 
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werden und in welcher Reihenfolge sie zur Abarbeitung, d.h. 
Ausfuhrung, gelangen sollen, wird in der Firmware-Konf igura- 
tion FWK festgelegt. In dieser steht also die Information, in 
welche Systemebene ein Code-Teil integriert werden soli und 
wenn in einer Systemebene mehrere Code-Teile integriert sind, 
in welcher Reihenfolge diese Code-Teile abgearbeitet werden 
sollen. 

Der Parameter-Teil PAR beinhaltet Oberflachen- und Bedienpa- 
rameter fur das Engineering-System (ES; FIG 1, FIG 4, FIG 8) 
als auch die Mechanismen fur das Run-Time- System (RTS; FIG 1, 
FIG 4, FIG 8), die eine Parametrierung ermoglichen. Damit hat 
der Anwender die Moglichkeit, Instanzen von Technologieob- 
jekttypen TO eines Technologiepaketes TP gemaS seinen Anfor- 
derungen zu parametrieren . 

Mit Hilfe der 1 bis n Sprachmechanismen SPR eines Technolo- 
giepakets TP lalSt sich der Sprachvorrat des Engineering- 
Systems (ES; FIG 1, FIG 4, FIG 8) um Befehle und Operatoren, 
die fur das zugrundeliegende Technologiepaket TP mit seinen 
zugehorenden 1 bis n Technologieobjekttypen TO adaquat und 
sinnvoll sind, erweitern. Sprachmechanismen SPR mussen ins 
Engineering- System (ES; FIG 1, FIG 4, FIG 8) und ins Run- 
Time-System (RTS; FIG 1, FIG 4, FIG 8) der Steuerung geladen 
werden. Nachdem solche Sprachmechanismen (z.B. "erhohe Tempe- 
ra tur") im Engineering- System (ES; FIG 1, FIG 4, FIG 8) in- 
stalliert wurden, sind sie im Compiler und in der Oberflache 
bzw. im Browser des Engineering-Systems (ES; FIG 1, FIG 4, 
FIG 8) bekannt und konnen vom Anwender in seinen Anwenderpro- 
grammen direkt verwendet werden. Durch eine Plug & Play- 
Technologie wird sichergestellt , dafi im Engineering-System 
(ES; FIG 1, FIG 4, FIG 8) bekannte Sprachmechanismen auch als 
ablauf f ahiges Codestuck im Run-Time-System (RTS; FIG 1, FIG 
4, FIG 8) vorhanden sind. Der Anwender veirwendet also die 
Spezif ikation der Sprachmechanismen, um die Implementierung 
im Run-Time- System (RTS; FIG 1, FIG 4, FIG 8) braucht er sich 
nicht mehr zu kiimmern. In der spater noch behandelten FIG 8 
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wird das Zusammenspiel von Zuladen, Verwenden und Abarbeiten 
von Sprachmechanismen SPR von -Technologiepaketen TP genauer 
erlautert werden. 

Zuruck zu FIG 6 : In der ACC-Komponente eines Technologiepa- 
kets TP befindet sich die Beschreibung aller Sprachelemente, 
die das Technologiepaket TP enthalt, die Beschreibung aller 
Systemvariablen und aller Typen, die im Technologiepaket TP 
verwendet werden. Die ACC-Komponente entspricht somit einem 
Deklarations- und Beschreibungsteil fiir das Technologiepaket 
TP. Diese ACC-Komponente wird in erster Linie ins Run-Time- 
System (RTS; FIG 1, FIG 4, FIG 8) der Steuerung geladen. Da- 
durch wird sichergestellt , daS sich alle Inf ormationen bzgl . 
vorhandener Technologiepaketen TP und Technologieobj ekttypen 
TO im Run-Time- System der Steuerung befinden und somit der 
AnschluS von Bedien- und Beobachtungsgeraten (z.B. Operator 
Panels) sehr leicht moglich ist. 

Nachfolgende Tabelle zeigt, wohin die Bestandteile des Tech- 
nologiepakets TP innerhalb der Steuerung geladen werden: ent- 
weder ins Engineering- System (ES; FIG 1, FIG 4, FIG 8) oder 
ins Run-Time- System (RTS; FIG 1, FIG 4, FIG 8). oder sowohl 
ins Engineering-System (ES; FIG 1, FIG 4, FIG 8) als auch ins 
Run -Time -System (RTS; FIG 1, FIG 4, FIG 8) . 





Xbmpo- ' 
nente 


wird 

geladen 

in: 


abiauffahiqer Code 


Code 


RT 


Parametrieroberflache (und entsprechendes Wissen uber die einzelnen Pa- 
rameter) 


PAR 


ES 


Konfigurations-lnformationen 

(Informationen. wie und wo die Teile in das Ablaufsystem eingeklinkt werden) 


FWK 


ES + RT 


Anwenderschnittstelle (Befehle (MOVE, POS. ...), SFCs, SFBs. Systemvari- 
ablen, ...) 


SPR 


ES + RT 


Anwenderschnittstelle (qraphische Informationen) 


SPR 


ES 


Beschreibungsinformationen fur Systemvariablen, Alarme, ... 


ACC 


ES + RT 


ObjekttVDen (Technoloqische Objekte) 


TO 


ES + RT 


Versionsinformationen fur Konsistenz zwischen RT, Paketen und Obiekten 


ACC 


ES + RT 



In der Darstellung gemaS FIG 7 werden als 00-Strukturdiagramm 
exemplarisch mogliche Technologieobj ekttypen (TO; FIG 6) fur 
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ein Technologiepaket (TP; FIG 6) Kunststoff TPK dargestellt. 
Bei der Kunststof fbearbeitung bzw. -erzeugung benotigt man 
iiblicherweise eine Temperaturregelung und eine Druckregelung . 
Der Druck, der dann auch durch den Druckregler DR geregelt 
werden muS, wird ublicherweise durch eine einfache Achse A 
aufgebaut, indem die Achse die Materialpaste zusairanenpreSt . 
Fur die Temperaturregelung sind in diesem Beispiel zwei Tem- 
peraturregler vorgesehen, ein schneller Temperaturregler TRS 
und ein langsamer Temperaturregler TRL. Wie aus dem 00-Struk- 
turdiagramm ersichtlich, leiten leiten sich der langsame Tem- 
peraturregler TRL und der schnelle Temperaturregler TRS aus 
dem allgemeinen Temperaturregler TR ab. Die beiden Tempera- 
turregler TRS und TRL, der Druckregler DR und die Achse A 
werden in dem vorliegenden Technologiepaket Kunststoff durch 
vier Technologieobjekttypen TO reprasentiert , namlich TRS, 
TRL, DR und A. Durch die Kardinalitat (Ziffer 1) wird ange- 
deutet, daS bei diesem Beispiel genau ein schneller TRS und 
ein langsamer Temperaturregler TRL, sowie genau ein Druckreg- 
ler DR und eine Achse A verwendet werden. Hinter dem schnel- 
len Temperaturregler TRS kann sich z.B. ein PID-Regler, hin- 
ter dem langsamen Temperaturregler TRL kann sich z.B. ein P- 
Regler verbergen, das sind aber Implementierungsdetails, die 
einen Anwender der Funktionalitaten dieser Technologieobjekt- 
typen im Engineering- System (ES; FIG 1, FIG 4, FIG 8) verwen- 
det, nicht zu interessieren brauchen. Ein Anwender kann somit 
die Funktionalitaten dieser Technologieobjekttypen (TO; FIG 
6) im Engineering- System (ES; FIG 1, FIG 4, FIG 8) verwenden, 
ohne sich um Implementierungsdetails kummern zu mussen. 

In der Darstellung gemaS FIG 8 wird gezeigt, daS aus einer 
Datenquelle D, die Beschreibungsinf ormationen fur Systemvari- 
ablen sowie gegebenenf alls Alarme und/oder Sprachbef ehle ent- 
halt, uber den Inf ormationspf ad 14 an den Umsetzer U ubermit- 
telt werden. Der Umsetzer U generiert aus den eingespeisten 
Daten Parametrierinf ormationen fur das Engineering-System 
ES4, fiir das Ausgabemedium AM und fur das Run -Time -System 
RTS4 , Der Umsetzer U wird vor der Compilierung der Run-Time- 
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bzw. Enginering-System-Sof tware aufgerufen. Er erzeugt Sour- 
cen, die dann bei der Erzeugung der Run-Time- bzw. Enginee- 
ring-System-Sof tware compiliert werden. Auf dem Inf orTtiations- 
pfad 15 werden vom Umsetzer U die Parametrierinf ormationen 
zum Engineering-System ES4 transf eriert . Die vom Umsetzer U 
erzeugten Parametrierinf ormationen fur die Dokumentation wer- 
-den uber den Inf ormationspf ad 16 an das Ausgabemedium AM, in 
FIG 8 dargestellt durch einen Drucker, weitergeleitet . Als 
Ausgabemedium ist aber auch beispielsweise eine Online-Hilfe 
am Bildschirm vorstellbar. Die vom Umsetzer generierte Para- 
metrierinf ormation fiir das Run-Time -System wird iiber den In- 
f ormationspfad 17 in das Ablauf ebenenmodell AE des Run-Time- 
Sy s t ems RTS 4 gel aden . 

Der Umsetzer U wird immer dann aufgerufen, wenn er aus der 
Datenquelle D uber den Inf oirmationspf ad 14 neue Parametrier- 
inf ormation erhalt. Der Umsetzer U erzeugt in einem solchen 
Fall neue Sourcen fur die Dokumentation, das Run -Time -System 
RTS4 und fur das Engineering-System ES4 . 

Beim Betrieb der Steuerung werden die ins Engineering- System 
ES4 geladenen Systemvariablen vom Run-Time-System RTS4 uber 
den Inf ormationspf ad 18 mit aktuellen Daten des technischen 
Prozesses versorgt. Der Anwender hat die Moglichkeit, bezug- 
nehmend auf den aktuellen Zustand des technischen Prozesses 
(TPl, TP2; FIG 1 bzw. FIG 4) weitere Eingaben am Engineering- 
System ES4 durchzuf uhren . 

iiber den Inf ormationspf ad 19 kann das Run-Time- System RTS4 
ein Gerat zum maschinennahen Uberwachen und Steuern (in FIG 8 
dargestellt durch ein Operator Panel OP) mit Inf ormationen 
(z.B. Alarmen) versorgen. 

Der Umsetzer U tritt beim Betrieb der Steuerung nicht mehr in 
Erscheinung. Die Inf ormationspf ade 14, 15, 16 und 17 werden 
bei der Erzeugung der Steuerungssof tware verwendet, aber 
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nicht beim Betrieb der Steuerung. Beim Betrieb der Steuerung 
werden die Inf ormationspf ade 18 und 19 verwendet. 
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Patentanspriiche 

1. Universelle Bewegungssteuerung mit Engineering- und Run- 
Time-System, welche funktionell die klassischen Aufgaben ei- 
ner speicherprogrammierbaren Steuerung und einer numerischen 
Steuerung in sich vereinigt, 

dadurch gekennzeichnet, 

dafi ein einheitliches Ablauf ebenenmodell (AE) dergestalt ge- 
bildet ist, daS es mehrere Ablauf ebenen unterschiedlichen 
Typs mit unterschiedlicher Prioritat aufweist, wobei von 
hochster bis niedrigster Prioritat verschiedene Anwender- und 
Systemebenen vorgesehen sind und dafi jeweils Technologiepake- 
te (TP) anwender sei tig in das Engineering- und/oder Run-Time- 
System (ES1-ES4, RTS1-RTS4) ladbar sind, daS eine Datenquelle 
(D) fur Beschreibungsinf ormationen fur Systemvariablen sowie 
gegebenenf alls Alarme und/oder Sprachbef ehle uber einen Um- 
setzer (U) dem Engineering- System (ES1-ES4) Sprachbef ehle 
und/oder Systemvariablen zur Verfugung stellt, daS aus dem 
Run-Time-System (RTS1-RTS4) die Systemvariablen mit aktuellen 
Daten des technischen Prozesses (TPl, TP2) versorgbar sind 
und daS liber eine Bedienoberf lache des Engineering-Systems 
(ES1-ES4) weitere Eingaben anwender sei tig machbar sind. 

2. Universelle Bewegungssteuerung nach Anspruch 1, 
dadurch gekennzeichnet, 

daS vom Umsetzer (U) aus dem Bestand der Datenquelle (D) re- 
levante Dokumentationsinf ormationen an ein Ausgabemedium (AM) 
we i ter le i tbar s ind . 

3 . Universelle Bewegungssteuerung nach einem der vorstehenden 
Anspriiche, 

dadurch gekennzeichnet, 
dafi als Ablauf ebenen vorgesehen sind: 
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a) eine Lagereglerebene, bestehend aus zugehoriger getakteter 
Systemebene und Anwenderebene , 

b) eine Interpolatorebene, bestehend aus zugehoriger getakte- 
ter Systemebene und Anwender ebene , 

c) eine Event -Systemebene fur reaktionspf lichtige Ereignisse, 

d) eine Anwenderebene fur asynchrone Fehler 

e) eine weitere, vom Anwender anf orderungsspezif isch frei 
projektierbare Anwenderebene (FA) fiir Alarm- und/oder E- 
vent- und/oder Regelungs- und/oder sonstige zyklische 
Tasks, 

f) eine aus der Abfolge von Bewegungssequenzen, freien Zyklen 
und niederprioren sonstigen Systemtasks, gebildete Ebenen- 
gruppe fiir Hintergrund-Bearbeitung, 

wobei die Ablaufebenen a bis e eine Ebenengruppe fiir Echt- 
zeit-Bearbeitung bilden, 

4. Universelle Bewegungssteuerung nach einem der vorstehenden 
Anspriiche, 

dadurch gekennzeichnet, 
dafi die Technologiepakete (TP) beinhalten: 

a) Code-Teile, die die Regelungsspezif ika fiir das Run- 
time-System (RTS1-RTS4) reprasentieren und 

b) einen Konf igurierteil (FWK) der die Zuordnung dieser Code- 
Teile zu den jeweiligen Systemebenen, sowie deren Bearbei- 
tungsfolge aufweist, wobei 

c) bedarfsweise diese Inf ormationen des Konf igurierteils 
(FWK) auch an das Engineering- System (ES1-ES4) weiterleit- 
bar sind. 

5. Universelle Bewegungssteuerung nach Anspruch 4, 
dadurch gekennzeichnet, 

daS die Inf ormationen des Konf igurierteils (FWK) eines Tech- 
nologiepaketes (TP) uber die Datenquelle D und den Umsetzer U 
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ins Run -Time -System {RTS1-RTS4) und ins Engineering- System 
(ES1-ES4) gebracht werden. 

6. Universelle Bewegungssteuerung nach Anspruch 4 oder 5, 
dadurch gekennzeichnet, 

daS jedes Technologiepaket (TP) eine angepafite Anzahl von 
Technologieobjekttypen (TO) fur das Run-Time-System (RTSl- 
RTS4) beinhaltet. 

7. Universelle Bewegungssteuerung nach Anspruch 4, 5 oder 6, 
dadurch gekennzeichnet, 

dafi des weiteren Bedienoberf lacheninf ormationen, insbesondere 
Bedienparameter (PAR) , und/oder Sprachmechanismen (SPR) 
und/oder Deklarations telle (ACC) den Code-Teilen zuweisbar 
sind. 
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Zusammenf assung 

Uni ver s el 1 e Bewegungs s t euerung 

Die in einer universellen Bewegungs steuerung UMC benotigten 
Parametrierinf ormationen (Beschreibungen von Systemvariablen, 
Alarmen und Sprachbef ehlen) werden iiber einen zentralen Um- 
setzer (U) aus einer einheitlichen Beschreibungssprache gene- 
riert und an Engineering- System (ES1-ES4), Run -Time -System 
(RTS1-RTS4) sowie Ausgabemedien (AM) fur die Dokumentation 
verteilt. Dadurch ist gewahrleistet , daS die Parametrierdaten 
fiir alle Systemteile konsistent sind. Dariiberhinaus konnen 
auch Konfigurierinf ormationen (FWK) von Technologiepaketen 
(TP) uber den Umsetzer U ins Engineering- (ES1-ES4) und ins 
Run-Time- System (RTS1-RTS4) der Steuerung gebracht werden. 
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